Before I start working on the TODOs of this PR, I wanted to understand what was going on here since I didn't experience any issues in the partitioned heat tutorial.
To this end, I ran some tutorials with subcycling and did some research about the copy function.

Tests (without the suggested fix)

1. Partitioned Heat equation
   I modified the heat.py file such that only one participant does subcycling.
   It seems like in this tutorial, the checkpointing doesn't affect the solution (or at least not so severely)
2. Elastic Tube 3D
   Similar to the perpendicular flap case, I set fenics_dt=precice_dt/5. The simulation crashed as well
3. Perpendicular Flap OpenFOAM-OpenFOAM
   Again, the solid participant does subcycling and this is what you'd get shortly before the program crash:
   
4. Perpendicular Flap Fluid Fake-FEniCS
   The picture speaks for itself:
   
5. Perpendicular Flap Fluid Fake-OpenFOAM
   After some time, the simulation explodes as well, but before that the flap does not become so wiggly as the one from 4. It is just bending to the right and grows.

What's wrong with copy() ?

Though in the current dolfin documentation about Function.copy(), the dof are deep copied, but as we use legacy FEniCS this is how the copy function is implemented (when I started looking at the documentation, I haven't considered that the dolfin version FEniCS uses is outdated; that's why I am pointing that out).
So, I think it is necessary to use a copy(deepcopy=true) with the current state of the adapter.

Since the odd behavior isn't solely restricted to the OpenFOAM-FEniCS perpendicular flap tutorial but also to cases where the FEniCS adapter isn't used at all, my guess would be that there is a bug elsewhere as well.

What do you think?

Since the odd behavior isn't solely restricted to the OpenFOAM-FEniCS perpendicular flap tutorial but also to cases where the FEniCS adapter isn't used at all, my guess would be that there is a bug elsewhere as well.

The OpenFOAM-OpenFOAM failure definitely makes this more confusing. Otherwise I could imagine that something goes wrong in the Python bindings, and hence all Python-based participants produce failures.

I could imagine that you have two independent issues here. Maybe ignoring OpenFOAM for the moment is the more sane strategy.

@NiklasVin I assume you already did this: Can you also do the experiment from above including the changes from precice/tutorials#554 but without deepcopy=true? I would assume that you do not see any problems in this case because you are avoiding the problem on the side of the user.

@NiklasVin I assume you already did this: Can you also do the experiment from above including the changes from precice/tutorials#554 but without deepcopy=true? I would assume that you do not see any problems in this case because you are avoiding the problem on the side of the user.

Exactly. I tested it without deepcopy=true and everything works fine.

Based on the current state I would still suggest to merge this PR and use deepcopy by default. Main reason: It makes the usage of the FEniCS adapter more secure and we cannot run that easily in issues like the one fixed via precice/tutorials#554. So generally I would consider this as a usability improvement at cost of performance. If we learn that the performance cost is too high, we could still offer an option to set deepcopy=false for experienced users that implement safe update schemes like in precice/tutorials#554.

@IshaanDesai, @uekerman, @NiklasVin: Any comments? If not, I would like to merge this PR.

Makes sense, lets merge this 👍

A short comment regarding the performance aspect: I tested the runtime of copying a dolfin function both with and without deep-copying. On average, the deep-copy variant is about 13% slower (only copying the function, not the whole execution of the simulation). So, the overall runtime shouldn't be affected too much, at least, it wasn't when comparing precice/tutorials#554 with the suggested changes here.
So, it makes sense to merge this.